前一天，我才拿十份陌生教材測試 Visual Learning Lab，發現原本自認穩定的系統，竟然有機會把「課本給定的數據」當成可以自由修改的參數。Day 27 花了不少時間補上來源事實與假設探索的區別，還有 Source 和視覺表示之間真正的語意連結。

原本以為這樣就能繼續往公開部署前進，但今天我想先確認一件更基本的事情：這個專案已經寫了 28 天，第一次打開它的人，真的知道怎麼用嗎？

所以 Day 28 我把重心從編譯器、Validator 和模型能力移開，找了兩位同學體驗，也讓 Codex 用隔離瀏覽器模擬不同類型的新手，專門挑介面問題。

兩種回饋我會分開記錄：同學給的是實際使用者的主觀感受；Codex 給的是可重現的瀏覽器操作觀察。它們都很有幫助，但不能混成「五位真人完成實驗」。

先找同學：視覺化有吸引力，但還不能說已經提升學習成效

這次我找了兩位同學來看 Visual Learning Lab 的使用方式，讓他們實際接觸教材與互動介面。

整體回饋比我預期的正面：他們認為，把抽象公式或變化關係改成看得見、能操作的形式，對理解概念有幫助，也比單看一段靜態說明更有參與感。

我把他們的正向感受整理成兩個值得繼續驗證的方向。

第一個是**「先看見變化，再回來理解公式」**。

例如簡諧運動裡的振幅與週期，原本只靠文字很容易把兩種效果混在一起；如果先看到圖形如何變高、變寬，再回頭對照公式，理解的切入點可能更直覺。

第二個是**「自己動手試，比只看答案更有感」**。

學習者不只看系統告訴他結果，還能透過改動參數觀察差別。

不過，上面是我對這次同學正面回饋的整理，不是兩位同學的逐字引述，也不是正式問卷結果。我們沒有做完整的前後測，也沒有把 PDF-only 和 VLL 隨機分組比較，所以今天不能宣稱「實測證明學習成效提升」。

比較準確的說法是：有初步正面的使用者感受，值得後續用更嚴謹的方法確認。

我也試著把這些好評轉成下一次真的可以檢查的改善方向，而不是只留下「大家覺得很好用」這句話。

比方說，如果圖形互動真的有幫助，學習者應該可以在調整振幅後，自己說出最大位移改變、但波峰間隔不變；調整週期後，則能解釋為什麼水平距離變長。

除了問喜不喜歡，還應該看他能不能用自己的話講出變化原因、能不能找到對應的課本公式。這次還沒完成那種程度的測驗，但至少知道下一次該驗證什麼。

另外，對真人回饋我也不想只挑稱讚的部分來寫。

站在產品設計角度，我會把「視覺化有幫助」繼續拆成三個問題：是不是更容易發現公式和圖形的關係、是不是更容易操作自己想探索的量，以及操作後是不是更容易解釋結果。

這三件事情分開記錄，未來才能真的把好評變成可行的改進。

而且我發現，有人願意說「這功能很有趣」和「他真的能自己走完操作流程」，其實是兩個不同的問題。這就是今天下一部分要處理的事。

讓 Codex 當挑毛病的新手，而不是當產品啦啦隊

除了真人回饋，我還安排了一輪 AI-Simulated Usability Red Team。

原本想測五種情境：不會寫程式的學生、看得懂公式但不熟 AI 的學生、沒有耐心的人、懷疑工具價值的人，以及想使用自己 PDF 的學生。

為了不讓它只在文字上幻想操作流程，我要求 Codex 實際打開隔離瀏覽器，從首頁開始點選。

測試不是讓它查原始碼找出正確按鈕，而是觀察畫面上提供了什麼提示、使用者可能在哪裡走錯路。

做完要留下實際操作、卡點、截圖與限制，沒有完成的步驟就標記為沒有完成。

這一輪不是五位真人，也不能產生真人問卷或學習成效分數。它的用途比較像自動化的 UX 挑錯：讓我們在正式公開以前，先抓到一些開發者自己很難注意到的死角。

第一個尷尬：公式找得到，控制項卻不知道藏在哪裡

簡諧運動是今天主要使用的準備示例。

它包含振幅、週期、相位與對應波形，原始 PDF 的公式也能在 Source 頁面定位。

第一個模擬情境實際把振幅從 3 改成 2.90，也能回到 Source。

表面看起來是成功的：控制項能動、數值更新、來源也還在。

可是 Codex 在操作時指出一個很實際的卡點：

從原始公式選到的可能是正式概念節點，不一定是可以直接調整的參數；真正的滑桿又藏在長長的流程圖下方。

對寫這套程式的人來說，我知道 Source Atlas、Formal Representation 和 Numeric Lab 分別放在哪裡。

但一個第一次使用的人，根本不應該先把這些架構名詞背起來，才能找到要操作的東西。

這是今天最重要的提醒：我花很多天做出 Source → Semantic Entity → Representation 的技術連結，卻沒有讓使用者很自然地走到「下一個可以做的動作」。

功能存在，不代表入口清楚。

第二個問題：看見數字更新，不等於看懂數字為什麼變

第二個模擬情境調整的是週期。

把週期改成 3.20 時，畫面顯示角頻率從約 2 更新到 1.9635，之後也能返回來源頁。

這段更新不需要重新詢問 OpenAI。

編譯好的 Numeric Lab 使用本地狀態重新計算，普通互動的模型請求增量是 0。

但我覺得比「成功更新」更值得問的是：

如果使用者不知道週期 T 和角頻率 ω 的關係，那他看到 1.9635，可能也只會覺得數字變了而已。

以簡諧運動來說：

ω = 2π/T

當週期變大，角頻率會下降；如果振幅保持不變，曲線主要是在時間軸方向拉長，而不是上下變高。

真正有幫助的學習介面，應該讓人能順著改動 → 圖形變化 → 公式原因 → 回到教材這條路理解，而不只是給出一個可以拉的 slider。

第三個問題：準備好的示範，居然還有按了會失敗的入口

還有一個問題比較好笑。

測試時使用的是離線準備示例，事先就禁止新增付費 AI 請求，但介面裡仍然留著「建立空間學習場景」按鈕。

模擬使用者自然就按下去了，結果只收到安全驗證失敗訊息。

這不代表正式線上分析失敗，因為那個測試模式本來就不允許新生成。

可是對使用者來說，他不知道這些背景限制，只知道「有一個按鈕，按下去卻做不到」。

所以我們重新整理了兩條應該明確區分的入口：

• 試用已準備好的示例
• 用自己的 PDF 進行正式分析

前者應該立即可以探索，不能假裝每一步都在即時生成；後者則需要真的走上傳與模型分析流程，並且清楚告知可能的等待與失敗。

第四、第五種情境，也讓限制變得比較清楚

後面的模擬情境並沒有讓結果突然變得完美。

對產品抱持懷疑態度的情境，來源查證只達到部分完成：Source Atlas 在該次準備內容裡可檢視的頁面只有 1–3 頁，使用者不一定能直覺理解這是來源準備範圍的限制，還是系統漏讀了教材。

另一個情境嘗試自行上傳 PDF，上傳有成功，但完整生成流程沒有測完。

這一點必須明講，因為「檔案傳得上去」和「陌生教材可以順利生成可用的學習世界」，中間還差很多步。

Day 27 的陌生教材測試也已經提醒過我，不能只拿成功的畫面來代表所有輸入。

另外，中文介面夾雜英文生成內容、不同 Representation 的名稱不一定容易理解，這些也被列入問題清單。

有些是本輪已觀察到的介面落差，有些例如長時間生成是否讓人放棄，仍然只是待驗證的風險，不能把猜測當測試結論。

如果把今天的問題排優先順序，最嚴重的其實不是字型或動畫，而是兩件事：

可操作控制項找不到，以及示範模式提供了不該出現的操作入口。

這次真的修了什麼？

我沒有打算趁 Day28 再重寫整個 UI。

前面已經做了不少次架構和視覺整理，現在剩下的時間更應該花在真正會阻礙使用者的問題上。

最後選擇修兩個地方。

第一個是 Source 頁面的操作入口。

當使用者選到有經過驗證的參數控制連結的概念時，現在可以從概念旁的入口直接前往真正的控制項，而且控制區會提前顯示，不再要求使用者一路捲過整張流程圖。

這個改動延續 Day27 建立的 Ownership Contract：有明確的語意連結才能導覽，不會因為兩個東西名稱很像，就硬湊成可拖動物件。

第二個是準備示例的入口。

新的離線入口明確告訴使用者：「內容已經預先生成，這次不發出新的 AI 請求。」

需要模型才能完成的操作在該模式下被停用，避免讓人一按就撞上註定失敗的訊息。

正式上傳自己的 PDF 仍然是另一條流程，原本的安全驗證沒有因為這次修 UI 而放寬。

這個修正也讓我更能體會，為什麼前一天花那麼多時間做 Semantic Ownership。

假設來源頁面出現一個彈簧恢復力的節點，但目前只有振幅與週期的 Numeric Lab 可以操作，系統就不能隨便把「恢復力」當成那兩個控制的同一個對象。

現在的做法是把有依據的關係拿來導覽，沒有依據的部分仍然保留成正式說明，不假裝每個來源公式都能直接拖。

這聽起來不像什麼華麗功能，卻能避免學習者被錯誤的介面暗示帶偏。

這兩個修改比較像是在把前 27 天的能力真正交到使用者手上，而不是增加新的技術賣點。

最後還是要測，不然又只是「我覺得變好用了」

這次完成修正後，Codex 先跑了針對性的測試，結果是 7/7 PASS；最後完整 Regression 是 500/500 PASS。

瀏覽器也實際驗證了改值、返回原文、來源保持不變，以及互動後 API delta = 0。

這些結果能支持「兩項 UX 修改沒有破壞原本的主要功能」，但不能直接推論所有新手都會滿意。

特別是我們只有兩位同學的初步主觀回饋，而 AI 模擬測試也不等於真人研究。

原本想做的 PDF vs Visual Learning Lab 學習對照實驗，今天沒有完成正式的成效驗證。

但我認為 Day28 仍然很值得。

以前我花很多力氣問「AI 能不能把這個概念編譯成互動世界」，今天開始會多問一句：

「一個根本不知道 Source Atlas 是什麼的人，能不能真的用到它？」

這也讓我重新理解 ChatGPT 和 Codex 在這個專案中的角色。

ChatGPT 幫我整理測試目標、區分使用者感受與工程證據；Codex 負責實際操作瀏覽器、暴露問題、修改程式與跑 Regression。

最後哪些問題值得優先修、哪些數據不能拿來宣稱成功，仍然需要我自己決定。

到了 Day28，我最想保留的結論是：

互動做得出來只是第一步；讓人找得到、知道自己在改什麼，而且可以回教材核對，才比較像真正能拿來學習的工具。

下一天就是 Day29。我準備把注意力轉到公開部署前最現實的問題：API 費用、授權、安全性、多人使用和失敗時的處理。

作品如果真的要交給別人使用，不能只有自己的電腦跑得順而已。